Internet payment system and method

ABSTRACT

A system and method for facilitating payment for online purchases is disclosed. The system allows consumers/customers who shop online to select, at the time of checkout, direct payment from an account as the payment option. An electronic bill (ebill), independent of any confidential financial information pertaining to the consumer, is automatically displayed and emailed to the consumer. The consumer pays the ebill at their bank the same way they pay their utility bill, which then results in a payment confirmation sent from the bank to the payee. Payment information from the bank is sent to the system to update the purchase transactions. Once the payment information is processed, the consumer and merchant accounts are balanced and both receive automatic notification of the payment.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is continuation-in-part of U.S. patent application Ser.No. 10/697,984, filed on Oct. 31, 2003, which is related to U.S.Provisional Patent Application No. 60/422,640 filed on Nov. 1, 2002 andU.S. Provisional Patent Application No. 60/506,873 filed on Sep. 30,2003.

FIELD OF THE INVENTION

The present invention relates to an Internet payment system and method.

BACKGROUND OF THE INVENTION

Currently users who have purchased goods and services over the Internetare faced with few payment options. The credit card companies dominatethe market, while the users pay high processing fees and shy away frommaking online payments for trust and security reasons. Digital cash haslower rates than credit card companies, but the adoption has been slowand there are no turnkey solutions still in place.

Some problems of the current methods include credit card fraud thatdeters users from using their credit card numbers on the web; high costof processing that deters merchants from setting up eCommerce sites; andinability to buy items from multiple merchants with one paymenttransaction that makes the process cumbersome.

SUMMARY OF THE INVENTION

An object of the present invention is to provide an improved Internetpayment system and method.

A payment method and system are provided using electronic media and inparticular the Internet to allow a secure and trusted exchange of money,to broaden the choices of users and allow merchants to receive paymentusing means other than credit cards and digital cash, to reduce the costof electronic transactions for both user and merchant and to allow usersto make payment for multiple merchants using a single account.

The Internet Debit Manager (IDM) functions as a payment processinginfrastructure that processes online purchases completed by buyers viaweb banking, telebanking and mobile banking. The present inventionsupports purchase processing, payment processing, as well as serviceprovider and merchant tools. The system is able to clear and settlefunds for both the buyers as well as merchants participating intransactions.

The system enables secure confidential debit payment for goods andservices purchased over the Internet. The system has flexible paymenthandling and supports payment flow from the bank to the service providerto the merchant or directly from the bank to the merchant.

The system allows consumers who shop online to select, at the time ofcheckout, direct payment from an account as the payment option. A billis automatically displayed and emailed to the consumer. The consumerpays the bill at their bank the same way they pay their utility bill,which then results in a payment confirmation sent from the bank to thepayee. Payment information from the bank is sent to the system manuallyby the service provider administrator using the Debit Manager interfaceor by running an automated batch process to update the purchasetransactions. Once the payment information is processed, the consumerand merchant accounts are balanced and both receive automaticnotification of the payment. The system also advises if underpayment oroverpayment has been made. The system handles error scenarios during theprocessing of the transaction and notifies consumer, merchant or serviceproviders with the necessary error codes and appropriate action thatneeds to be taken.

In accordance with an aspect of the present invention there is provideda payment processing system for facilitating payment for online purchasetransactions comprising: a merchant interface, a messaging manager, apayment interface, an account settlement module, and a database. Themerchant interface receives, from an online merchant, purchasetransaction information related to an online purchase transaction by aconsumer. The purchase transaction information includes merchant andconsumer account identification, a transaction description, and atransaction amount related to the online purchase transaction. Thepurchase transaction information is independent confidential financialinformation pertaining to the consumer.

The messaging manager generates an electronic bill based on the receivedpurchase transaction information. The electronic bill includes thetransaction description, amount due, payment due date, and payeeinformation to which payment for the online purchase is made at afinancial institution trusted by the consumer thereby avoidingdisclosure of the consumer's confidential financial information to theonline merchant.

The payment interface receives, from the financial institution, paymentinformation upon payment of the electronic bill by the consumer, andprovides, to the online merchant and the consumer, a paymentnotification. The account settlement module processes parsed paymentinformation and allocates payments to outstanding online purchasetransactions. The database stores information pertaining to the onlinemerchant, the consumer, and the electronic bills associated with theonline purchase transactions.

In accordance with another aspect of the present invention there isprovided a payment method for online purchase transactions. According tothe method, purchase transaction information related to an onlinepurchase transaction by a consumer is received from an online merchant.The purchase transaction information includes online merchant andconsumer account identification, a transaction description, and atransaction amount related to the online purchase transaction. Thepurchase transaction information is independent of confidentialfinancial information pertaining to the consumer.

An electronic bill based on the received purchase transactioninformation is generated and provided to the consumer. The electronicbill includes the transaction description, amount due, payment due date,and payee information to which payment for the online purchase is madeat a financial institution trusted by the consumer, thereby avoidingdisclosure of the consumer's confidential financial information to theonline merchant. Payment information is received, from the financialinstitution, upon payment of the electronic bill by the consumer. Basedon parsed payment information, payments are automatically allocated tooutstanding online purchase transactions. The payments are routed tooutstanding online purchase transactions based on data introspectionaccording to predefined rules. The online merchant and the consumer areprovided a payment notification. Information pertaining to the onlinemerchant, the consumer, and the electronic bills associated with theonline purchase transactions is stored in a database.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be further understood from the followingdetailed description with reference to the drawings in which:

FIG. 1 illustrates a payment processing system in accordance with anembodiment of the present invention;

FIGS. 2 a, 2 b, and 2 c are flow charts illustrating processes for setup, purchase and payment, respectively, for the system of FIG. 1 inaccordance with an embodiment of the present invention;

FIG. 3 illustrates a functional block diagram the modules of the systemof FIG. 1 in accordance with an embodiment of the present invention;

FIG. 4 illustrates, in bold, the modules of the system of FIG. 1 used toprocess a purchase transaction in accordance with an embodiment of thepresent invention;

FIG. 5 illustrates, in bold, the modules of the system of FIG. 1 used toprocess a payment transaction in accordance with an embodiment of thepresent invention;

FIG. 6 illustrates, in bold, the modules of the system of FIG. 1 used tosend a message in accordance with an embodiment of the presentinvention;

FIG. 7 illustrates, in bold, the modules of the system of FIG. 1 used toprovide business to business transactions in accordance with anembodiment of the present invention; and

FIG. 8 illustrates an alternate embodiment of the system of FIG. 1 forInternet card loading.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Generally, the present invention provides a system and method forfacilitating payment for online purchases. The system allowsconsumers/customers who shop online to select, at the time of checkout,direct payment from an account as the payment option. An electronic bill(ebill), independent of any confidential financial informationpertaining to the consumer, is automatically displayed and emailed tothe consumer. The consumer pays the ebill at their bank the same waythey pay their utility bill, which then results in a paymentconfirmation sent from the bank to the payee. Payment information fromthe bank is sent to the system to update the purchase transactions. Oncethe payment information is processed, the consumer and merchant accountsare balanced and both receive automatic notification of the payment.

Referring to FIG. 1, there is illustrated a payment processing system inaccordance with an embodiment of the present invention. The paymentprocessing system or IDM service provider 10 facilitates payments foronline purchases made by a user or consumer 80 at an online merchant 82.The IDM service provider 10 supports the online transaction during thepurchase loop and the payment loop, as shown in FIG. 1 and describedbelow.

As is typical in an online or e-commerce transaction, a consumer 80accesses merchant web sites 82 via the Internet. The consumer 80 selectsthe goods and services they wish to purchase by filling a shopping cart(step 1). The merchant 82 displays a payment web page to the consumer 80at checkout with one or more payment options, one of which includes thedebit payment option according to an embodiment of the presentinvention. If the consumer 80 selects the debit payment option, themerchant 82 sends purchase details of the consumer's order to the IDMservice provider 10 (step 2). The IDM service provider 10 then generatesand provides an ebill to the consumer 80 showing, among otherinformation, the order details, amount due, and due date along withinstructions to the consumer 80 to make payment to the indicated payeeusing the payee's assigned account number at a financial institution 84of the consumer's choice (step 3). The ebill is independent of anyconfidential financial information pertaining to the consumer.

Upon receipt of the ebill, the consumer 80 completes payment of theebill at the chosen financial institution 84 (step 4). Once thefinancial institution 84 processes the payment, payment logs orinformation is sent to the IDM service provider 10 (step 5). The IDMservice provider 10 processes the payment information and providesnotification (receipt) of the payment to the merchant 82 and theconsumer 80 (step 6). Shipment and fulfillment of the order occurs afterreceipt of notification of payment by the merchant 82 (step 7). Themerchant 82 receives payment directly from the financial institution 84or through the IDM service provider 10 (step 8).

The financial institution 84 (such as an RPPS—Remote Payment andPresentment Service or ePay) provides an existing infrastructure forpayment or electronic funds transfer from a consumer's bank account tothe IDM service provider or the online merchant's bank account using anonline banking payment system (these accounts could be at the sameinstitution or at different institutions). The financial institutionnetwork can be an existing remittance and payment-processing network forregistered bill and consumer service providers (e.g., for utilitycompanies).

FIGS. 2 a, 2 b, and 2 c are flow charts illustrating processes for setup, purchase and payment for the system of FIG. 1 in accordance with anembodiment of the present invention. An online merchant 82 that wishesto offer web banking as a payment option (debit payment option) foronline purchases of goods or services contacts the IDM service provider10 to receive integration information. Once the registration form iscompleted, the information is setup on the IDM system database (to bedescribed later) along with a unique account id and number identifyingthe merchant 82.

Prior to the purchase and payment process, the IDM service provider 10and/or the online merchant 82 is set up as a payee with financialinstitutions, in accordance with an embodiment of the present invention,as shown in FIG. 2 a. The IDM Service Provider 10 registers itself as apayment receiver with all major banks 84 (step 100). Alternatively, anonline merchant account is created with the IDM service provider 10 andeither the IDM service provider 10 or the online merchant 82 isregistered as a payment receiver (payee) with the financial institutions84 (step 102). This process is only performed once before the system isdeployed. At the completion of this step any person or consumer 80 canvisit their banks web page, mobile banking or telebanking and search forthe payee name. Once the company information is displayed a user addspayee to their bill list. The online merchant 82 integrates theirshopping cart (direct payment as check out option) with the IDM serviceprovider 10 (step 104).

Currently all transaction processing software components are onlycapable of processing payments based on one account—one merchant basis.For example, each Utility Company creates an account number for eachclient or consumer, which limits the client to only pay that particularutility. The system according to the present invention leverages theexisting banking infrastructure and improves it by allowing users to paymultiple merchants using one account through the IDM service provider.

FIG. 2 b illustrates, in a flow chart, the purchase process inaccordance with an embodiment of the present invention. The methodprovided enables merchants to accept debit payments for online purchasesas follows. A user/consumer visits the merchant website and selects thegoods or services they wish to purchase (step 110). Once the userdecides to proceed to checkout and selects direct payment from accountas the payment option the transaction information is posted to the IDMservice provider system via the Merchant Integration ApplicationProgramming Interface API (to be described later) (Step 112).

Each Transaction includes the merchant identification and at least onepurchase item. Each purchase item has a positive dollar value attachedto it. The transaction also includes all mandatory fields and correctfield formats as defined by the Merchant Integration API.

The information passed may include the payment occurrence indicatingwhether the transaction is a single payment or re-occurring payment andthe type of the transaction, for example, Test or Live. For re-occurringpayment the frequency of the payments is also passed to the IDM serviceprovider system.

The information passed may include overdue account informationindicating the terms of sales to be applied to overdue accounts. Thisinformation will be applied to any reminder bills generated. Forexample, a merchant may pass net “30, 1.5%, overdue reminder=yes”. Afterthirty days if the account remains unpaid an ebill reminder will be sentincluding the 1.5% interest charges against the transaction.

The transaction information is checked for errors (step 114). Any errorsdetected are returned to the IDM service provider system or presented tothe user (step 116). Either the user or the merchant's systemadministrator must correct the error in order to proceed with thepurchase.

Verification is made as to whether an account exists for the user in theIDM service provider system. The consumer is then authenticated as auser of the payment system (step 118). If the consumer is a new user, anaccount is created and the consumer is provided their accountinformation and password (step 120).

The consumer is displayed a confirmation page to accept the purchaseorder and consent to the direct (web banking) payment method (step 122).A transaction is created in the IDM service provider database andflagged as payment pending (step 124). All transaction information istracked in the IDM service provider system, as discussed later.

An ebill is emailed to the consumer showing, among others, the orderdetails, amount due, due date and instructing them to make payment tothe payee using the payee's assigned account number at their own bank(step 126). The process now enters the payment loop (step 128) asillustrated in detail in FIG. 2 c. As described earlier, the ebill isindependent of any confidential financial information pertaining to theconsumer.

FIG. 2 c illustrates, in a flow chart, the payment process in accordancewith an embodiment of the present invention. This method enablesmerchants to process bank payment notifications as follows. Consumersvisit their banks online (or in person), and pay their bills, using theaccount number and amount specified in the ebill (step 130). The firsttime the user makes an online payment; they also add the paymentreceiver to the list of vendors in their bill list. Thus, payment forthe online purchase is made at a financial institution trusted by theconsumer thereby avoiding disclosure of the consumer's confidentialfinancial information to the online merchant.

On a scheduled basis, the banks send the payment receiver, i.e., the IDMservice provider or the merchant, an electronic feed for thetransactions completed (step 132). Upon receipt of the paymentinformation, the IDM service provider process the information eitherautomatically or manually.

For automatic processing, the IDM service provider system receives thepayment information files from the banks, parses them, extracts the dataand populates the system database making the appropriate entries in theconsumer account tables. The process also notifies the user that thepayee received a payment and that further action is required on theirpart if they chose the manual payment processing option to complete thetransaction.

For manual processing, such as for smaller operations, the bank feed canbe received via fax and the database manually updated by an authorizedadministrator. The administrator will use the debit manager interface(to be described later) to enter account number and amount received fromthe bank. The system will then update the database records. The processalso notifies the user that the payee received a payment and thatfurther action is required on their part if they chose the manualpayment processing option to complete the transaction.

Each consumer can choose to allocate funds manually or let the AccountSettlement module process the payments in relation to one or moretransactions, and route the payment to an order based on a matchingalgorithm. The matching algorithm performs data introspection accordingto predefined payment routing rules, for example, based on merchantoperating needs. The matching algorithm can include any number ofcriteria and/or comparisons, on the basis of which the payment can berouted to one or more orders or transactions. Money can then be creditedto each matching transaction and marked as Paid. Unpaid transactionsretain their status as payment pending. The consumer account carries abalance if the were insufficient funds to cover the bill.

If the consumer chooses to allocate funds manually, then each time apayment is made at the bank, and the processing is completed by thesystem as outlined above, the consumer is sent an email and is asked torevisit the system and complete the transaction by allocating the fundsappropriately. When the consumer logs into their Wallet (to be describedbelow), they see a list of their outstanding transactions and accountbalance. The consumer manually allocates funds to each transaction.Transactions that have been completed successfully are marked as paymentcomplete. The remaining balance is credited to the consumer's account;outstanding transactions remain as payment pending. Based on thetransaction requirements, the consumer can only allocate full paymentagainst any specific transactions; partial payment may not be accepted.

The system verifies if sufficient payment has been received (Step 136).If the consumer makes a decision to allocate the funds automatically,the Account Settlement module (to be described below) of the system willprocess the payments. For example, payments can be processed daily usingthe following three scenarios.

Scenario 1: The amount deposited equals the amount owing in theconsumers account. In such a case all transactions are processed, andmarked as payment completed (step 138).

Scenario 2: The amount paid is larger than the amount owing on theconsumer account. In such a case all transactions are credited and theirstatus is changed to payment competed. The remaining funds will remainin the consumers account and can be refunded or used at a later time tocomplete other payments against future transactions (step 140).

Scenario 3: If the money paid is less than the total amount owing on alltransactions, then Account Settlement processes the transactionsstarting with the service that was purchased first, money is credited toeach transaction and marked payment completed. Once the systemdetermines that cash on hand is not sufficient to complete atransaction, the process stops. The remaining transactions retain theirstatus as payment pending. The remaining funds stay in the usersaccount. A transaction summary and account status is then emailed to theconsumer (step 142).

The merchant has the option of sending reminder bills to consumers withover due accounts. The bill sent to the consumer may reflect theoutstanding balance, and interest incurred and a total owing.

The IDM system will now be described in further detail with reference toFIG. 3. FIG. 3 illustrates, in a functional block diagram, the on-linedirect debit payment system in accordance with an embodiment of thepresent invention. The system 10 includes a Service Layer 12, ProcessLayer 14 and Business Components Layer 16 that communicate with adatabase 18.

The service layer 12 includes a presentation view 20 having a merchantadministration module 22, a service provider administration module 24, aconsumer wallet 26 and a forms module 28. The service layer 12 alsoincludes a merchant interface 30 having a merchant integration APImodule 32, a service layer business-to-business (B2B) interface 34. Theservice layer also includes a payment interface 36.

The process layer 14 includes business logic and data conversion andshares persistent objects 40 and 42 with the service layer 12 andbusiness component layer 16, respectively. The process layer 14 acts asa messenger between the service layer 12 and business component layer16. It takes requests from service layer 12, performs first levelvalidations on inputs, does data conversion on the inputs and passes iton to the business component layer 16 for further validations and datastorage functions. The process layer 14 takes responses from thebusiness component layer 16 and passes it to the service layer 12 in theappropriate formats.

The business component layer 16 includes a user authentication module44, a transaction processing module 46, a payment manager module 48, abusiness component B2B interface 50 and a sales tool module 52. Thepayment manager 48 includes a debit manager module 54, an accountsettlement module 56, a messaging manager module 58 and a billingmanager 60. The business component B2B interface 50 includes aconfiguration manager 62, a scheduler 64 and a secure transfer module66.

Referring to FIG. 4, there is illustrated, in bold, the modules of thesystem 10 of FIG. 3 used to process a purchase transaction in accordancewith an embodiment of the present invention.

The modules of the system 10 that interact to process a purchasetransaction are shown in FIG. 4. The modules include the merchantintegration API module 32, the user authentication module 44, thetransaction processing module 46, the debit manager module 54, theaccount settlement module 56, and the messaging manager module 58.

The Merchant Integration API 32 receives information in an HTML post,XML or client server secure interface. The information includes themerchant identification and at least one purchase item. Each purchaseitem has a positive dollar value attached to it. The transaction alsoincludes all mandatory fields and correct field formats as defined bythe Merchant Integration API 32.

The general format of the purchase information passed to the IDM systemin the HTML post is shown below as an example:

<form action=https://www.modasolutions.com/MODAPay/ ProcessPayment “method=“POST”> <input type=hidden name=merchant_id value=“MP0001”><input type=hidden name=item_name_1 value=“computer”> <input type=hiddenname=item_desc_1 value=“DELL Dimension”> <input type=hiddenname=item_amount_1 value=“1400”> <input type=hidden name=item_quantity_1value=“1”> <input type=hidden name=item_name_2 value=“Monitor”> <inputtype=hidden name=item_desc_2 value=“Samsung 14″ LCD”> <input type=hiddenname=item_amount_2 value=“1400”> <input type=hidden name=item_quantity_2value=“1”> <input type=hidden name=item_count value=“2”> <inputtype=hidden name=currency value=“CAD”> <input type=hidden name=cmdvalue=“_mTrans”> </form>

The system 10 is capable of processing single or recurring payment. Forrecurring payments the frequency of the payments is also passed to thesystem 10. The payment schedule is stored in the database 18. Thebilling manager 60 is invoked periodically and searches due bills andsends the information to the messaging manager 58 to prepare and deliverthe necessary bills to the user or consumer 80. For single billing, thetransaction process invokes the billing manager 60 in real-time.

The system 10 is capable of managing overdue accounts. To enable thisfeature the information passed includes overdue account informationindicating the terms of sales to be applied to overdue accounts. Thebilling manager 60 applies this information to any reminder billsgenerated. For example, a merchant may pass net “30, 1.5%, overduereminder=yes”. After thirty days if the account remains unpaid, an ebillreminder will be sent including the 1.5% interest charges against thetransaction.

System generated errors are returned to the system or presented to theuser. Either the user or the merchant's system administrator mustcorrect the error in order to proceed with the purchase.

The system 10 includes a User Authentication or Verification Module 44.Prior to the system 10 committing a sales transaction to the database18, the consumer information is passed to the user authentication module44. If the consumer is a new user the user authentication module 44 ofthe system 10 creates an account, the system returns the account andpassword information for the consumer to accept.

The system is also capable of receiving bulk purchase information in abatch process. This information is passed through the Merchant Interface30 to the system via HTML or XML. The system processes batch purchasesthe same way it processes individual requests made to the MerchantIntegration API 32.

Referring to FIG. 5, there is illustrated, in bold, the modules of thesystem 10 of FIG. 3 used to process a payment transaction in accordancewith an embodiment of the present invention.

The modules of the system that interact to process a payment transactionare shown in FIG. 5, in bold. These modules include the merchantadministration module 22, the payment interface 36, the process layer14, the debit manager module 54, the account settlement module 56, themessaging manager module 58 and the database 18.

In one embodiment, the payment information is received electronicallyand is processed by the system 10. The Payment Interface 36 receivespayment information in an electronic feed from the banks. The PaymentInterface 36 may be configured to receive the files and information indifferent formats to accommodate different banks. The payment interface36 parses the information to ensure that it is in the pre-defined bankformat. For example, ACH format on the RPPS network. The parsing of theinformation may be triggered manually through the merchantadministration view 22 or scheduled to run at different intervals.

All generated errors are written to a log file. The errors must becorrected in order to proceed with the processing of the payment file.

The Account Settlement module 56 processes all valid paymenttransactions by extracting the data and populating the database 18. Theaccount settlement module 56 processes parsed payment information andallocates payments to outstanding online purchase transactions. Thesystem is capable of managing correct payments, overpayment andunderpayment. The transactions are processed as follows:

When the amount received equals the amount owing in the consumersaccount all transactions are processed, and marked as Paid.

When the amount received is larger than the amount owing on the consumeraccount all transactions are credited and their status is changed toPaid. The account balance will reflect the unused portion of the amountreceived.

When the amount received is less than the total amount owing on alltransactions, the Account Settlement module 56 processes the payment inrelation to one or more transactions, and routes the payment to an orderbased on a payment matching algorithm. The payment-matching algorithmincludes steps to perform data introspection according to predefinedrules defined, such as rules based on merchant operating needs. Thematching algorithm can include any number of criteria and/orcomparisons, on the basis of which the payment can be routed to one ormore orders or transactions. Money can then be credited to each matchingtransaction and marked as Paid. Unpaid transactions retain their statusas payment pending. The consumer account carries a balance if the wereinsufficient funds to cover the bill.

The payment process triggers the Messaging Manager module 58 to notifythe user that a payment has been received, the status of the account andif further action is required on their part to complete the transaction.

In a second embodiment, the payment information is received by fax andentered into the system manually. The transactions are manually typedinto the Debit Manager 54 by entering the account number and amountreceived from the bank. The system 10 then processes the transactionsthe same way it processes the electronic feeds.

Referring to FIG. 6, there is illustrated, in bold, the modules of thesystem 10 of FIG. 3 used to send a message in accordance with anembodiment of the present invention.

As shown in FIG. 6 the messaging manager 58 receives system calls fromthe Merchant Interface 30, Account Settlement module 56 and BillingScheduler/Manager 60 to trigger the sending of a message.

The system call includes parameters such as message type, messageformat, preconfigured account number and transaction reference number.Based on these parameters the message manager 58 queries the database 18for the content of the message.

The type of messages generated by the messaging manager 58 are,typically, ebill, Payment Reminder, Payment Received, Over Payment,Insufficient Payment, Coupons, and Order Cancellation or Amendment. Thecontent of each of the messages may be system default or composed usingthe merchant interface 30 and stored in the database 18. The automaticsending of a message may be suppressed. The messaging manager 58 sendsemail, or messages in SMS and MMS formats.

An embodiment of the invention further includes a method of facilitatingconsumers to manage their account funds using the Consumer Wallet 26 inan Internet browser. The Consumer Wallet 26 queries the database 18 topresent a history of transactions, a list of outstanding transactionsand the account balance. Available funds can be allocated to unpaidbills and the Account Settlement module 56 updates the database 18.Bills that have been completed successfully are marked as Paid. Theremaining balance is credited to the consumers account; outstandingtransactions remain as payment pending.

Using a GUI interface a consumer can choose to allocate funds manuallyor configure the Account Settlement 56 module to allocate money on theirbehalf using a payment matching algorithm, such as First in first out(FIFO) system. When the “Allocate Funds Manually” option is enabled,each time a payment transaction is processed the Messaging Manager 58sends the consumer an email instructing the consumer to log on to thesystem to complete the transaction by allocating the fundsappropriately.

The system 10 includes a module known as the Service ProviderAdministration Tool 24. Service Provider Tools 24 enable serviceproviders to offer the system as a service to their merchant base. TheService Provider Administration is an application accessed through anInternet browser that allows authorized administrators to view andmanage the information pertaining to their merchants, transactionsbilling, and merchant reimbursements stored in the database 18.

The Service Provider Administration Tools 24 provide the followingfunctionality: view, search, sort, and edit merchant account informationbelonging to that service provider; setup and tear down merchantaccounts; view, search, sort transaction information generated by theirmerchants; view, search, sort consumer account information; generatemerchant statements; and reconcile settlement with merchants.

The Service Provider Administration Tools 24 also allow serviceproviders to retrieve records of all payments received for a specifiedperiod of time and to flag transaction records as “reimbursed” whenpayments of funds have been reimbursed to the merchants.

The system 10 includes a module known as the Merchant AdministrationTools 22. The Merchant Administration Tools 22 is an applicationaccessed through an Internet browser that allows authorizedadministrators to view and manage the information stored in the database18.

The Merchant Administration Tools 22 provide the followingfunctionality: view, search, sort, and edit consumer account informationbelonging to that merchant; setup and tear down merchant accounts; view,search, sort transaction information generated by their consumer;perform bill adjustments; view, search, sort consumer accountinformation; generate consumer statements; generate and configuremessage manager; and reconcile settlement with payees.

The Merchant Administration Tools 22 also allow merchants to retrieverecords of all payments received for a specified period of time and toretrieve records of all payments reimbursed by the payee for a specifiedperiod of time.

In addition, Merchant Tools such as sales closing tools enable merchantsto send various notifications as follows.

Systems notifications—enable merchants to select default systemgenerated emails to be sent to buyers. As an example, the merchant canselect a “Thank you for buying” email that is sent to consumers who paiddirectly. Another example is when merchant can send a “reminder to pay”email for those with payment pending status

Merchant defined notifications—enables merchants to compose and sendemails to buyers who completed their payments or people who have notpaid yet. These emails are typically not predefined and can be writtenby the merchant and may include the opportunity for cross-selling or upselling. The system supports text-based emails and formatted based ones.

Wireless SMS/MMS Systems notifications—enables merchants to selectpredefined system generated SMS or MMS messages to be sent to buyers ontheir mobile phones. As an example, the merchant can select a “Thank youfor buying” SMS that is sent to consumers who paid directly. Anotherexample is when merchant can send a “reminder to pay” SMS/MMS for thosewith payment pending status.

Wireless merchant defined notifications—enables merchants to compose andsend SMS or MMS messages to buyers who completed their payments orpeople who have not paid yet. These emails are typically not predefinedand can be written by the merchant and may include the opportunity forcross-selling or up selling.

In an embodiment of the system 10, the merchant administration enablesmerchants to make adjustments to existing bills. The bill adjustmentincludes bill presentment to the administrator and the functions toperform order cancellations, item cancellation, and item modifications.Adjustments to orders can trigger the account settlement module 56 tomake the required changes to the consumer account when billing isaffected. The message manager 58 can be automatically or manuallyinvoked to send notification of the change to the consumer.

Another embodiment of the invention includes a system for generating andsettling coupons. The system comprises of an interface to create andmanage the coupons, a database to store coupon details and the methodthat enables merchants to send coupons once the ebill has been receivedby the buyer. The coupon contains the consumer account and the discountamount that is applied to a purchase or left in the account for futurepurchases. The coupon management interface accepts individual coupons orbatch loading of coupons into the system. When a payment is processedthe Account Settlement module 56 searches the database 18 for couponsthat are linked to the consumer account and applies the discount tosettle the account balance.

Coupon issuing enables merchants to send coupons once the buyer hasreceived the ebill. The coupon can include discounts that can be used toreduce payments or a credit that can be left in account for futurepurchases.

In an exemplary scenario, below is a walkthrough of how coupon issuingcan work. A buyer fills a shopping cart, checks out and selects directpayment from bank account. The buyer then receives an ebill by emailwith the payment amount specified in the ebill. The merchant uses thecouponing tools to issue a $100 discount coupon. The coupon can beissued at the same time the ebill is emailed or sent by the merchant ata later time to motivate the buyer to complete payment. Upon receivingthe coupon, the buyer pays for entire amount less than the $100 coupon.The system processes transaction and matches the transaction with theaccount and settles the account.

Coupon creation and distribution module enables a coupon to be createdvia the web manually and sent via email to the buyer; a coupon to becreated via the web manually and sent via SMS/MMS to the buyer; a batchof coupons to be uploaded to the system and sent to buyers by email; abatch of coupons to be uploaded to the system and sent to buyers bySMS/MMS; and enables the merchant to define a credit coupon or adiscount coupon.

Discount coupons can be applied against an outstanding bill. Creditcoupons can be applied any time after the coupon is issued.

The Coupon Processing module enables the system to store, track, andprocess coupons sent to the buyer. The module maps coupon numbers to anaccount number held by the buyer. The module enables discounts couponsto be matched against outstanding bills. On processing of transactionsthe number of coupons are matched against the ebill amount. The moduleenables credit coupons to be added to the buyer's account. The systemprocesses the credit coupons and updates the balance in the buyer'saccount.

Yet another embodiment of the system includes enabling merchants todefine the payment schedule for recurring payments. The payment schedulecan be defined on a weekly, monthly, or quarterly basis. The methodenables merchants to track the number of recurring payments completed bythe buyer. For example, merchant can view the administrator reports anddetermine that consumer x has completed 3 out of 7 payments. Themerchant can also have the option to utilize any of the resourcesavailable by the system such as notifications and coupons.

Another embodiment of the system includes enabling the merchants to useLeasing Tools to break down the amount of a transaction into multiplesmaller amounts. An example of this scenario is as follows: A merchantsells $1000 computers, which a buyer wants to buy but cannot afford thefull amount. The buyer agrees for the merchant's leasing program andselects leasing terms. The system sets up transaction as a recurringpayment transaction and manages the ebills, the interest on the leasingas well as the conditions and policies in the event of a non-payment.

Referring to FIG. 7, there is illustrated, in bold, the modules of thesystem 10 of FIG. 3 used to provide business-to-business transactions inaccordance with an embodiment of the present invention.

The system 10 includes a module known as the business component B2BInterface 50 that interfaces on the backend with third partyapplications such as sales order processing and accounting systemsresiding in the merchants' premises. The order processing information isexported off the system over an HTML or XML service layer B2B interface34. As shown in FIG. 7 the business component B2B Interface includesthree components viz., Configuration Module 62; Scheduler Module 64; andSecure Transfer Module 66.

The configuration module 62 is used to record in the database 18 thebatch processing triggers, information to be transmitted, interfacedestination, output formats and error handling destination.

The scheduler 64 runs to invoke the secure transfer of the orderinformation on a scheduled basis. The secure transfer module 66establishes a secure link with the host destination. A file is createdand the information is transferred to the host destination.

Referring to FIG. 8, there is illustrated communication with the systemof FIG. 3 for Internet card loading in accordance with an embodiment ofthe present invention. Internet Card Loading is a method that enablesmerchants and consumer acquirers to load prepaid value cards using theIDM system. The stored value cards could be one of the following:prepaid credit cards; prepaid phone cards used for land line/mobiletelephony; prepaid value cards run and owned by the provider of the IDMsystem.

In an exemplary embodiment, as illustrated in the FIG. 8, the followingsteps highlight the functionality of the Internet Card Loadingoperation. A user 80 visits merchant site 82 that is selling prepaidcards. The user selects card, and the amount of money to be loaded andsubsequently receives an ebill. The user pays the ebill at their bankaccount using the pre-assigned account number. The funds are nowallocated in the user's account. The system 10 maps the account numberto the prepaid card number. The mapping enables prepaid card to be usedas desired by the user 80.

The Internet loading can happen in multiple possible configurations. Forexample, the merchant 82 assigns an account to the consumer 80 and mapsthe IDM account to the prepaid cards. Alternatively, the merchant 82configures the system 10 to issue accounts that are equivalent to theprepaid cars. Once the account is loaded, there is no need for mappingbetween multiple accounts to be made.

In summary, purchase processing supports an API to accept userauthentication information and purchase transaction details from ashopping cart or other web application such as an invoicing or eventmanagement application. Purchase processing also enables posting oftransaction information to the IDM database, and triggers electronicbill delivery and electronic receipt delivery.

Payment processing allows processing by batch or individually of bankpayment logs. Payment processing also allows consumers to allocate fundsto purchases as desired when multiple pending payments exist. Processedpayments can trigger automatic notification of incomplete payment, overpayment and full payment received.

Merchant tools allow merchants to view, search and sort transactions,manage sales transactions, export data from the IDM system, generatenotification and marketing messages over SMS, email, MMS or instantmessaging, generate coupons, and create pre-assigned consumer accounts.

Service Provider Tools allows administrators to view, create andmaintain merchant and user accounts and settle merchant reimbursements.

It is contemplated that each merchant may assign one or moreadministrators to maintain support of the system and to track and managetransactions. All administrators are given access to a sophisticatedreporting and management tool.

A merchant can have two options for system interface based on theirlevel of sophistication and size of business. The merchant can use webbanking with IDM Service Provider online order form 28 or integrate webbanking with shopping cart software using the Merchant Integration API,as shown in Step 104 of FIG. 2 a.

The merchant can choose to be the payee or chose the service provider tobe the payee. When the merchant is the payee, the consumers will maketheir bill payments directly to the merchant via their bank and the bankwill pay the merchant. When the service provider is chosen to be thepayee, the consumer will make their bill payments to service providervia their bank. The bank will pay the Service Provider, which will thenreimburse the merchants.

The system can also include a default or configurable “Checkout” button.This graphic and text can be inserted in HTML web pages, emails orelectronic documents to enable buyers to select the direct pay at mybank option. The preconfigured/default option includes presentation andtext.

It is also contemplated that the system 10 can support embedded paymentsin direct marketing campaigns. The system enables merchants topreauthorize prospective buyers and send them marketing campaigns thatinclude pre-assigned account numbers that enable the buyer to pay forthe items enclosed in the campaign. In an exemplary embodiment, themerchant compiles list of potential prospects and sends campaign to thelist with details of product/service in the body of the email. Thesystem assigns a predefined account number to the buyer. The buyerreceives email, reads information and then decides to pay using thepre-defined account for merchant's product/service. The Buyer can clickon a button that routes to a pre-filled form in which the user reviewsinformation and then confirms a request for an ebill if payment has notbeen made to the pre-defined account. The user then carries on with thepayment process as defined throughout this document. In the alternative,the buyer has the opportunity to proceed and pay from their bank accountto the pre-defined account number without requesting an ebill.

Enterprise Deployment: It is contemplated that the system 10 can besupported as a software license that can be hosted on the web ordeployed at the consumer premise behind a firewall. A software licensewith installable tools to be deployed on standalone redundant serversand has all the modules to support direct payment from bank account.

Backend interfaces enable merchants to pull data from the IDM system viaa XML interface; Proprietary interface; and Email. The backendinterfaces also enable the IDM to push the data via a XML interface orInstallable software at merchant premise that retrieves data from thesystem and presents it on the screen. The data from IDM containinginformation deposited in the database and passed to the system throughthe frontend interface includes, among other information, transactiondetails; payment status; sales closing information; and coupon usageinformation.

Another embodiment extends the system to mobile phones, wirelessdevices, and PDAs that enables the purchase loop and the payment loop tobe executed on a mobile device. In the form of an installable softwaremodule on a mobile device with menus and functionality that enablesbuyer to complete purchase and or payment loop on their mobile deviceand to manage their account status, payments and profiles.

Wireless adaptation enables merchants to offer web-banking payments forpurchases completed from a wireless device.

The IDM engine can be built using any CGI Web enabled programminglanguage, along with any data storage facilities. For example, JAVA,JSP, xHTML, Oracle can be used to build the engine. There are severalclasses and database tables required to implement this engine. Alsothere are shell scripts and EDI used to transfer and extract the databetween the banks and IDM.

The IDM interface is also available for immediate use by clients withaccess to an IP enabled mobile phones. Since IDM wired interface iswritten using xHTML the translation to a wireless devise isinstantaneous and requires minimal code modifications

The IDM interface can also be developed to accommodate mobile devicesthat require a mobile interface. For this purpose IDM can be supportedusing different technologies such as J2ME Web services, ASP.NET, Pythonand other technologies.

The mobile device can use navigation where a user can easily allocatefunds using their mobile towards their IDM account. Once the payment isreceived by the IDM the data is processed in the same manner as before.An email is sent out as well as an SMS message (if client is set up withthe service) instructing the client to allocate payments towards thetransactions. The Wireless banking module is then invoked from the mainmenu, where a user is then displayed the balance in their account and alist of transactions that are pending. The user can then select eachitem and hit the enter button on their phone. Once the button isselected, the appropriate tables are updated and the correspondingemails and SMS/MMS messages are sent.

Embodiments of the invention can be represented as a software productstored in a machine-readable medium (also referred to as acomputer-readable medium, a processor-readable medium, or a computerusable medium having a computer-readable program code embodied therein).The machine-readable medium can be any suitable tangible medium,including magnetic, optical, or electrical storage medium including adiskette, compact disk read only memory (CD-ROM), memory device(volatile or non-volatile), or similar storage mechanism. Themachine-readable medium can contain various sets of instructions, codesequences, configuration information, or other data, which, whenexecuted, cause a processor to perform steps in a method according to anembodiment of the invention. Those of ordinary skill in the art willappreciate that other instructions and operations necessary to implementthe described invention can also be stored on the machine-readablemedium. Software running from the machine-readable medium can interfacewith circuitry to perform the described tasks.

The above-described embodiments of the invention are intended to beexamples only. Alterations, modifications and variations can be effectedto the particular embodiments by those of skill in the art withoutdeparting from the scope of the invention, which is defined solely bythe claims appended hereto.

What is claimed is:
 1. A payment processing system for facilitatingpayment for online purchase transactions comprising: a merchantinterface to receive, from an online merchant, purchase transactioninformation related to an online purchase transaction by a consumer, thepurchase transaction information including merchant identification,payment processing system account identification for the consumer, atransaction description, and a transaction amount related to the onlinepurchase transaction, the purchase transaction information beingindependent of confidential financial information pertaining to theconsumer; an electronic bill manager to generate an electronic billbased on the received purchase transaction information and send theelectronic bill to the consumer, the electronic bill including thetransaction description, amount due, payment due date, and payeeinformation specifying the payment processing system as a payee to whichpayment for the online purchase is made at a financial institutiontrusted by the consumer thereby avoiding disclosure of the consumer'sconfidential financial information to the online merchant and thepayment processing system; a payment interface to receive, from thefinancial institution, payment information indicating the consumer hasdirected the financial institution to pay the electronic bill in favorof the payee, and to provide, to the online merchant and the consumer, apayment notification; an account settlement module to process parsedpayment information and to allocate payments to outstanding onlinepurchase transactions from an account of the payment processing systemto appropriate online merchants; and a database, to store informationpertaining to the online merchant, the consumer, and the electronicbills associated with the online purchase transactions.
 2. The paymentprocessing system as claimed in claim 1, further comprising: a userverification module to verify the existence of an account related to theconsumer in the database based on the payment processing system accountidentification for the consumer and to create a consumer account in theabsence of an existing consumer account prior to generating theelectronic bill.
 3. The payment processing system as claimed in claim 2,wherein the merchant interface provides error notifications to theonline merchant or the consumer for correction prior to generating theelectronic bill.
 4. The payment processing system as claimed in claim 1,further comprising: a billing manager to provide overdue payment andrecurring billing information in accordance with a billing schedule tothe electronic bill manager to generate overdue and recurring electronicbills.
 5. The payment processing system as claimed in claim 1, whereinthe payment interface provides the payment notification through theelectronic bill manager.
 6. The payment processing system as claimed inclaim 1, wherein the payment interface receives payment informationelectronically from the financial institutions or through manual dataentry into a debit manager.
 7. The payment processing system as claimedin claim 1, wherein the payment interface parses the paymentinformation, upon automatic or manual trigger, to provide the paymentnotification and to update the database.
 8. The payment processingsystem as claimed in claim 1, further comprising a consumer walletmodule to facilitate management of the consumer account by the consumer.9. The payment processing system as claimed in claim 8, wherein theaccount settlement module allocates payments to outstanding onlinepurchase transactions automatically or as manually allocated by theconsumer through the consumer wallet.
 10. The payment processing systemas claimed in claim 9, wherein the payment interface provides, to theconsumer and to the online merchant, a payment complete, an over paymentor an insufficient payment notification for outstanding online purchasetransactions upon allocation of payments.
 11. The payment processingsystem as claimed in claim 9, further comprising a coupon interfacemodule to generate online coupons for use against pending or futureonline purchase transactions and to send the coupons to the consumer viathe electronic bill manager.
 12. The payment processing system asclaimed in claim 11, wherein the account settlement module matchescoupons against pending online transactions and allocates payments inconjunction with the terms of the coupons.
 13. The payment processingsystem as claimed in claim 9, further comprising a leasing tool tomanage leasing options for online purchase transactions.
 14. The paymentprocessing system as claimed in claim 13, wherein the account settlementmodule allocates payments in conjunction with the leasing optionassociated with the online purchase transaction.
 15. The paymentprocessing system as claimed in claim 1, further comprising a serviceprovider administration tool to allow authorized service providers toview and manage information pertaining to one or more online merchants.16. The payment processing system as claimed in claim 15, furthercomprising business to business interface to interface with third-partyapplications residing in the online merchant or service providerpremises.
 17. The payment processing system as claimed in claim 1,further comprising a merchant administration tool to allow the onlinemerchants to view and manage information pertaining to themselves andtheir consumers.
 18. The payment processing system as claimed in claim17, wherein the merchant administration tool allows the online merchantsto modify or delete pending online purchase transactions.
 19. Thepayment processing system as claimed in claim 1 wherein the accountsettlement module routes payments to a plurality of transaction forwhich payment is pending.
 20. The payment processing system as claimedin claim 1 wherein the payment processing system is configured toregister itself as a payee with a plurality of financial institutions.